НАЗВАНИЕ¶

socket - создать оконечную точку коммуникации

КРАТКАЯ СВОДКА¶

#include <sys/types.h>
#include <sys/socket.h>

int socket(int domain, int type, int protocol);

ОПИСАНИЕ¶

socket создает оконечную точку для коммуникации и возвращает её дескриптор.

Параметр domain задает "домен" коммуникации; выбирает набор протоколов, которые будут использоваться для коммуникации. Такие наборы описаны в <sys/socket.h>. В настоящее время понимаются такие форматы:

Сокет имеет указанный тип, type, задающий семантику коммуникации. В настоящее время определены следующие типы:

SOCK_STREAM

Обеспечивает надежные, двунаправленные последовательные потоки байтов, с поддержкой соединений. Может также поддерживаться механизм вне-поточных данных.

SOCK_DGRAM

Обеспечивает датаграммы (ненадежные сообщения с ограниченной максимальной длиной, без поддержки соединения).

SOCK_SEQPACKET

Обеспечивает последовательный двунаправленный канал передачи датаграмм с поддержкой соединений; датаграммы имеют ограниченную максимальную длину; от получателя требуется за один раз прочитать целый пакет.

SOCK_RAW

Обеспечивает доступ к низкоуровневому сетевому протоколу.

SOCK_RDM

Обеспечивает надежную доставку датаграмм без гарантии их последовательности.

SOCK_PACKET

Устарело и не должно использоваться в новых программах; см. packet(7).

Некоторые типы сокетов могут не быть реализованными в некоторых наборах протоколов; например, SOCK_SEQPACKET не реализовано в наборе AF_INET.

Параметр protocol задает конкретный протокол, который используется на сокете. Обычно существует только один протокол, обеспечивающий конкретный тип сокета в заданном наборе протоколов. Однако, возможно существование нескольких таких протоколов -- тогда и используется этот параметр. Номер протокола зависит от используемого “домена коммуникации”, см.  protocols(5). См. getprotoent(3), где описано, как сопоставлять имена протоколов их номерам.

Сокеты типа SOCK_STREAM являются дуплексными потоками байт, похожими на трубы. Они не сохраняют границы между записями. Потоковый сокет должен быть в соединённом состоянии перед тем, как по нему можно отсылать и принимать данные. Соединение с другим сокетом создается с помощью системного вызова connect(2). После соединения данные можно передавать, используя системные вызовы read(2) и write(2), или какой-то из вариантов системных вызовов send(2) и recv(2). Когда сессия закончена, выполняется close(2). Вне-поточные данные могут передаваться, как описано в send(2), а приниматься, как описано в recv(2).

Коммуникационные протоколы, которые реализуют SOCK_STREAM, следят, чтобы данные не были потеряны или продублированы. Если у корреспондента имеется место в буфере, но очередная порция данных не может быть передана за разумное время, то соединение считается мертвым. Когда на сокете включен флаг SO_KEEPALIVE, протокол каким-либо способом проверяет, что другая сторона ещё жива. Сигнал SIGPIPE появляется, если процесс посылает или принимает данные, пользуясь разорванным потоком; это приводит к тому, что неопытные процессы, не обрабатывающие сигнал, завершаются. Сокеты SOCK_SEQPACKET используют те же самые системные вызовы, что и сокеты SOCK_STREAM. Единственное отличие в том, что вызовы read(2) вернут только запрошенное количество данных, а остаток прибывшего пакета будет отброшен. Границы между сообщениями во входящих датаграммах сохраняются.

Сокеты SOCK_DGRAM и SOCK_RAW позволяют посылать датаграммы корреспондентам, заданным при вызове send(2). Датаграммы обычно принимаются с помощью вызова recvfrom(2), который возвращает следующую датаграмму с соответствующим обратным адресом.

SOCK_PACKET --- это устаревший тип сокета, позволявший получать необработанные пакеты прямо от драйвера устройства. Используйте вместо него packet(7).

Системный вызов fcntl(2) с аргументом F_SETOWN может использоваться, чтобы задать группу процессов, которая будет получать сигнал SIGURG, когда прибывают вне-поточные данные или сигнал SIGPIPE, когда соединение типа SOCK_STREAM неожиданно обрывается. Этот вызов также можно использовать, чтобы задать процесс или группу процессов, которые получают асинхронные уведомления о вводе-выводе с помощью SIGIO. Использование F_SETOWN эквивалентно использованию ioctl(2) с аргументом SIOSETOWN.

Когда сеть сообщает протоколу об ошибке (в случае IP, например, используя ICMP-сообщение), то для сокета устанавливается флаг ожидающей ошибки. Следующая операция с этим сокетом вернет код ожидающей ошибки. Для некоторых протоколов можно разрешить для конкретного сокета очередь ошибок, чтобы получить детальную информацию об ошибке; см. IP_RECVERR в ip(7).

Операции сокетов контролируются их параметрами. Эти параметры описаны в <sys/socket.h>. setsockopt(2) и getsockopt(2) используются, чтобы установить и получить параметры, соответственно.

ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ¶

В случае ошибки возвращается -1; в противном случае возвращается дескриптор, ссылающийся на сокет.

ОШИБКИ¶

EPROTONOSUPPORT

Тип протокола или указанный протокол не поддерживаются в этом домене.

ENFILE

Ядру не хватило памяти, чтобы создать новый сокет.

EMFILE

Переполнение таблицы файлов процесса.

EACCES

Не разрешено создание сокета указанного типа и/или протокола.

ENOBUFS или ENOMEM

Недостаточно памяти. Сокет не может быть создан, пока не освободится память.

EINVAL

Неизвестный протокол, или недоступный набор протоколов.

Другие ошибки могут быть сгенерированы нижележащими модулями протоколов.

СООТВЕТСТВИЕ СТАНДАРТАМ¶

4.4BSD (системный вызов socket появился в 4.2BSD). Обычно переносимо с/на не-BSD системы, имеющие реализацию сокетов BSD (включая варианты System V).

ЗАМЕЧАНИЕ¶

Для наборов протоколов под BSD 4.* используются константы PF_UNIX, PF_INET и т. д., тогда как AF_UNIX и т. п. используются для указания семьи адресов. Однако же, страница руководства из BSD обещает: "Вообще, набор протоколов совпадает с семьей адресов", и в последующих стандартах везде используется AF_*.

СМОТРИ ТАКЖЕ¶

accept(2), bind(2), connect(2), getprotoent(3), getsockname(2), getsockopt(2), ioctl(2), listen(2), read(2), recv(2), select(2), send(2), shutdown(2), socketpair(2), write(2)

“Вводное Руководство по межпроцессной коммуникации в 4.3 BSD” (“An Introductory 4.3 BSD Interprocess Communication Tutorial”) перепечатано в Дополнительные документы для программиста UNIX, Том 1, (UNIX Programmer's Supplementary Documents Volume 1).

“Руководство по межпроцессной коммуникации в BSD” перепечатано в Дополнительные документы для программиста UNIX, Том 1, (UNIX Programmer's Supplementary Documents Volume 1).

ПЕРЕВОД¶

Copyright (C) Alexey Mahotkin <alexm@hsys.msk.ru> 1999